shell: Remove the "half-off" mode of the host switcher #20825
Conversation
e570c8d
to
18d3b87
Compare
|
Just FTR: My thought process was that the actual danger is about connecting to new unknown machines. Machines which you already have trusted/used in the past pose a much much lower threat. OTOH, disabling connecting to existing machines is a much bigger feature change/"regression" as new/unknown ones. But if @garrett and you are fine with dropping this right away, then no veto from me. I planned it for the near future anyway (https://issues.redhat.com/browse/COCKPIT-1150), but wanted to give our users a little warning time. What you do here is that you'd lose this feature entirely when upgrading from e.g. Fedora 40 to 41 or RHEL 9 to 10. |
Yes. But I don't think we are actually helping people with a half-on, half-off mode. Its restrictions are just going to be annoying. Instead of connecting to a new host, we make them figure out that they can edit one of their existing entries to point to a different IP address. Or add hosts by hacking localStorage. Or finally putting the override into place to enable host switching properly. If the OS has decided to switch the switcher off, but people rely on it, we should push them directly to enabling it again fully after upgrade, via the release notes. Also, we should inform them of the security implications of connecting to remote hosts more loudly, immediately before it happens, and then let them do it if they want. Imo. :-) |
|
Right, we know for a fact that people — including our RHEL customers — do use and depend on this feature, and they also do not realize the implications (even according to that call we had a couple months back)... but removing features that people use is tricky and really needs to be rolled out over time, hence disabling the host switcher to off for RHEL-only for now (rawhide too is arguable) and making it clearer what's going on, with solutions that are mentioned within Cockpit, would be a better way of doing this. We buy a little bit of time by changing the default config and dropping off the confusing half-off mode so we can design and implement more polished solutions for everyone (not just folks who will use RHEL10)... but we're still able to turn it completely off by default for RHEL10 (where it should also be mentioned in the release notes) in the immediate term, so we're still achieving the same main goal without breaking things for everyone else. Outline with details @ #20823 (comment) (based on the meeting Marius and I had) |
|
@mvollmer yes, this wasn't a veto, just explaining my thought process and the (IMHO) inconsistency in between simultaneously being concerned about breaking user cases and pushing for making the transition faster. If you deem this preferable, I'm fine with it! |
Breaking the workflow isn't a "warning". Showing the warning a bit more obviously would be a better warning. Since it's been the status quo for years, we need to make sure we're not outright breaking things in a half-complete state. Most people using the feature to connect to other machines will be doing so with their own machines on their own network. Connecting to and running apps on any remote machine has an inherent security risk to some degree in general, but when someone admins their own machine and uses trusted software from their distribution with containers and VMs on top, that risk is mitigated a lot. (And that's what people using Cockpit are going to almost always be doing.) Connecting to "new" machines from within Cockpit will almost always be machines under their control as admins, not random "unknown" machines. The security risk of connecting to another machine that isn't on the list yet will be relatively the same as connecting to one of the ones they've already connected to, in practice. (That is: They control the machines already.) I'm not saying we shouldn't handle this issue; I'm saying that we should stage the rollouts of changes in a better way without breaking the workflow in surprising ways inbetween. We also shouldn't change things in unfinished ways across all distributions to address a RHEL-specific issue. (I consider the "half-off" switcher unfinished in both idea and implementation.) Anyway, reverting this and changing the config file to be similar to what we already have across all distributions except RHEL is the way to gain some more time to have a more fully baked solution for everyone. Thankfully, having a config file and just turning it off for RHEL by default (with a way to enable it again if someone knows what they're doing) should fit the RHEL requirements and not leave it in a half-working state for everyone else meanwhile. |
9bc6a20
to
b160ed5
Compare
b160ed5
to
66b5357
Compare
032bea2
to
dc8e4a0
Compare
a80ea07
to
ddb2f64
Compare
ddb2f64
to
11e1480
Compare
225ad6e
to
8873e76
Compare
|
#20841 landed, so this can be rebased |
Cockpit should either not connect to remote machines at all, or trust the user to do it right. Also, the better place to explain the security implications of connecting to remote hosts is when actually connecting.
6230be1
to
a2b430c
Compare
| // remote machines via URL bookmarks or similar that point to | ||
| // them. | ||
| if (!host_switcher_enabled) | ||
| state.host = "localhost"; |
There was a problem hiding this comment.
Arg, have to switch the host switcher off explicitly to reach this, of course...
a2b430c
to
3d791d2
Compare
3d791d2
to
6be336a
Compare
6be336a
to
3cb143f
Compare
test/verify/check-system-realms
Outdated
| @@ -437,7 +437,7 @@ class CommonTests: | |||
| do_test(alice_user_pass, ['HTTP/1.1 200 OK', '"csrf-token"'], session_leader='cockpit-session', retry=True) | |||
|
|
|||
| # enable cert based auth | |||
| m.write("/etc/cockpit/cockpit.conf", '[WebService]\nClientCertAuthentication = true\n', append=True) | |||
| m.write("/etc/cockpit/cockpit.conf", 'ClientCertAuthentication = true\n', append=True) | |||
There was a problem hiding this comment.
This change is ugly. It relies on the previous content of cockpit.conf.
The fundamental problem is that we can not repeat sections in the file, so this will be rejected:
[WebService]
foo = 12
[WebService]
bar = 8
I think this could be allowed.
There was a problem hiding this comment.
That's the bug: on hosts where multihost is still enabled, it's missing the [WebService] header. So this needs to become another if/then.
|
There's a couple of flakes, but this systematically breaks client cert auth:
This somehow looks as the JSON protocol leaks through HTTP? |
| m1.write("/etc/cockpit/cockpit.conf", | ||
| '[WebService]\nAllowMultiHost=yes\n') |
There was a problem hiding this comment.
This would be better as if self.multihost_enabled(): m.execute('"rm .../cockpit.conf") else: self.enable_multihost()
There was a problem hiding this comment.
done (not quite exactly as above)
test/verify/check-system-realms
Outdated
| @@ -437,7 +437,7 @@ class CommonTests: | |||
| do_test(alice_user_pass, ['HTTP/1.1 200 OK', '"csrf-token"'], session_leader='cockpit-session', retry=True) | |||
|
|
|||
| # enable cert based auth | |||
| m.write("/etc/cockpit/cockpit.conf", '[WebService]\nClientCertAuthentication = true\n', append=True) | |||
| m.write("/etc/cockpit/cockpit.conf", 'ClientCertAuthentication = true\n', append=True) | |||
There was a problem hiding this comment.
That's the bug: on hosts where multihost is still enabled, it's missing the [WebService] header. So this needs to become another if/then.
...when the host switcher is disabled. Instead, redirect them to localhost. The tests that use multiple machines add those machines by navigating to their URL and then logging into them via the trouble shooting dialog. Those tests have to explicitly enable the host switcher for this to continue to work.
3cb143f
to
b2c92d6
Compare
|
I fixed the test as above, and mopped up the new pixel ref. @mvollmer please check my interdiff. If this goes green, I'm happy with this. Thanks a lot for your work! |
|
known flake, but retrying (lots of 3x affected) |
Yay, thanks a lot! |
Cockpit should either not connect to remote machines at all, or trust the user to do it right. Also, the better place to explain the security implications of connecting to remote hosts is when actually connecting.